Conventionally, when an appropriate array size is unknown in allocating an array, a programming pattern (hereinafter, referred to as an “array extension pattern”) is used in which an array of a small size is at first allocated, and as occasion demands, an array of an extended size is allocated. FIG. 13 shows an example of the array extension pattern. In a StringBuilder class shown in FIG. 13, a constructor firstly allocates a char[ ] array having elements of 16 (see (a) in FIG. 13). Then, in setting a value in an element of the char[ ] array by an append method, an if statement is used to judge whether or not the array needs to be extended. When the if statement holds true, a newchar[ ] array of a double size is newly allocated (see (b) in FIG. 13). Values of the elements of the original array char[ ] are copied to elements of the newly allocated array newchar[ ].
However, the use of the aforementioned programming pattern causes a problem of unnecessary execution, because the initial size of the array is often too large or too small. In particular, when being allocated frequently due to their short lives, arrays suffer from high overhead in zero initialization and copying.
Non-patent Literature 1 exists as a conventional technique relating to a method of selecting an initial size of a variable length object. Non-patent Literature 1 discloses the following method of selecting an initial size, focusing on a collection object as a variable length object. 1. When a collection object is allocated, a call context therefor is acquired and is recorded in an object information structure of the allocated collection object. 2. The type and the number of times of method calls for the collection object are recorded in the corresponding object information structure. 3. When the collection object is discarded, records of the corresponding object information structure are summarized, and the results are stored in a per-allocation-call-context information structure. 4. After the end of program execution, an appropriate initial size of the collection object is proposed to a programmer based on the summarization results.
Hence, suppose that the technique disclosed in Non-patent Literature 1 described above is applied to processing of determining an initial array size. Information of access to an array allocated at the two code parts (a) and (b) shown in FIG. 13 and allocation call context information of the array are recorded in corresponding object information structures, and the recorded information is summarized to be stored in the per-allocation-call-context information structure. Thereby, an appropriate initial size of the arrays allocated at the parts (a) and (b) can be proposed to the programmer. In this case, however, profile information of the recorded information can be summarized only on an allocation call context basis. Accordingly, feedback of the profile information of the array allocated at the part (b) cannot be given to an allocation call context of the array allocated at the part (a). This can consequently avoid allocation of too large arrays in the parts (a) and (b), but cannot eliminate array extension processing and reduce the number of times thereof.
Hereinbelow, descriptions are given of other literature found in a prior art research for the present invention.
Patent Literature 1 discloses the following technique. Specifically, the size of a variable length instance of an inline-allocation source is predicted by a method using an execution profile or the like. For example, suppose a case of predicting that the size of an array is 4. When the array length which is determined during execution is 4 or smaller, the array is inline-allocated in an inline-allocation destination instance. When the array length exceeds 4, the array is allocated separately from the allocation destination instance. However, in the technique in Patent Literature 1, the size of the variable length object to be allocated is profiled at each allocation code part, and there is no consideration for which element of the variable length object is actually accessed during the execution. Accordingly, the technique in Patent Literature 1 cannot optimize the array extension pattern.
Patent Literature 2 discloses an array area reservation apparatus including a calculation unit and an execution unit. Specifically, in a case where a memory space needs to be changed during execution of a program, the calculation unit refers to an environment setting file, and thereby calculates an optimum array length value required in the program, on the basis of the maximum or minimum array length in the environment setting file and an actual memory of a machine executing the program. The execution unit then changes the array length in the source program, and recompiles and executes the program. The technique in Patent Literature 2, however, is a technique of adjusting the size of the array to be allocated in the program according to the memory space of the machine executing the program, and is not a technique of adjusting the size according to elements of a variable length object actually accessed during the execution. Accordingly, the technique in Patent Literature 2 cannot optimize the array extension pattern.
Patent Literature 3 discloses a first method of dynamically reserving or releasing an array area in the C++ language. A memory management table and the size thereof are implemented as private member variables. The memory management table stores a pointer to a pointer array, the pointer pointing at the start of the pointer array to a data area, the pointer array including pointers pointing at lines of the data area in an array. In addition, an initialization function constructor, a memory reservation function, a memory release function, and a release function destructor are implemented as public member functions, the initialization function constructor being configured to initialize the memory management table, the memory reservation function being configured to reserve and allocate an array area, the memory release function being configured to release the area, the release function destructor being configured to release the data area and the array of pointers to the data area by using the memory release function. The technique in Patent Literature 3, however, is a technique for setting the size of a high-dimensional array in a multi-dimensional array as a run-time variable, instead of a compilation-time constant. With this technique, an allocated array is not extended during execution. Accordingly, the technique in Patent Literature 3 cannot optimize the array extension pattern.